Upstream some more Git for Windows' patches - #2195
Open
dscho wants to merge 13 commits into
Open
Conversation
Member
Author
|
/submit |
|
Submitted as pull.2195.git.1785939999.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -524,6 +518,7 @@ ifeq ($(uname_S),Windows) | |||
| NO_POSIX_GOODIES = UnfortunatelyYes | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> The "dashed form" has been officially deprecated in Git version 1.5.4,
> which was released on February 2nd, 2008, i.e. a very long time ago.
> This deprecation was never finalized by skipping these hard-links, but
> we can start the process now, in Git for Windows.
Good. Perhaps somebody (you do not have to volunteer) can champion
their removal from everywhere at Git 3.0 version boundary?
Thanks.
| @@ -465,14 +465,8 @@ ifeq ($(uname_S),Windows) | |||
| GIT_VERSION := $(GIT_VERSION).MSVC | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> - ifeq (CLANGARM64,$(MSYSTEM))
> - prefix = /clangarm64
> - else
> - prefix = /mingw64
> - endif
> + ifneq (,$(MSYSTEM))
> + prefix = $(MINGW_PREFIX)
> endif
Mental note: if $(MSYSTEM) is not an empty string, we set prefix to
$(MINGW_PREFIX).
> @@ -755,6 +749,10 @@ ifeq ($(uname_S),MINGW)
> BASIC_LDFLAGS += -Wl,--dynamicbase
> endif
> ifneq (,$(MSYSTEM))
> + ifeq ($(MINGW_PREFIX),$(filter-out /%,$(MINGW_PREFIX)))
> + # Override if empty or does not start with a slash
> + MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
> + endif
Mental note: MINGW_PREFIX that does not begin with a slash is forced
to begin with a slash.
> prefix = $(MINGW_PREFIX)
And that becomes $(prefix).
> diff --git a/meson.build b/meson.build
> index 7073d5844d..6ddc461873 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1318,7 +1318,6 @@ elif host_machine.system() == 'windows'
>
> libgit_c_args += [
> '-DDETECT_MSYS_TTY',
> - '-DENSURE_MSYSTEM_IS_SET',
> '-DNATIVE_CRLF',
> '-DNOGDI',
> '-DNO_POSIX_GOODIES',
> @@ -1328,6 +1327,18 @@ elif host_machine.system() == 'windows'
> '-D__USE_MINGW_ANSI_STDIO=0',
> ]
>
> + msystem = get_option('msystem')
> + if msystem != ''
> + mingw_prefix = get_option('mingw_prefix')
> + if mingw_prefix == ''
> + mingw_prefix = '/' + msystem.to_lower()
> + endif
> + libgit_c_args += [
> + '-DENSURE_MSYSTEM_IS_SET="' + msystem + '"',
> + '-DMINGW_PREFIX="' + mingw_prefix + '"'
> + ]
> + endif
Lowercase mingw_prefix in Meson world corresponds to MINGW_PREFIX in
Make world, I guess. -DMINGW_PRFIX gets mingw_prefix which begins
with a slash.
I do not do Windows or Meson, but doesn't this contradict with what
we have in [12/12], part of which says:
diff --git a/config.mak.uname b/config.mak.uname
index 2f7d445eb3..0b63be10b7 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -535,7 +535,9 @@ endif
compat/win32/pthread.o compat/win32/syslog.o \
compat/win32/trace2_win32_process_info.o \
compat/win32/dirent.o
- COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
+ COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY \
+ -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" -DMINGW_PREFIX="\"$(patsubst /%,%,$(MINGW_PREFIX))\"" \
+ -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -ENTRY:wmainCRTStartup -SUBSYSTEM:CONSOLE
# invalidcontinue.obj allows Git's source code to close the same file
# handle twice, or to access the osfhandle of an already-closed stdout
IOW, -DMINGW_PREFIX passed to the compiler strips leading slash from
$(MINGW_PREFIX).
Isn't it necessary to strip the leading slash from ming_prefix also
on the Meson side?There was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Junio,
On Wed, 5 Aug 2026, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> [...]
> > diff --git a/meson.build b/meson.build
> > index 7073d5844d..6ddc461873 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1318,7 +1318,6 @@ elif host_machine.system() == 'windows'
> >
> > libgit_c_args += [
> > '-DDETECT_MSYS_TTY',
> > - '-DENSURE_MSYSTEM_IS_SET',
> > '-DNATIVE_CRLF',
> > '-DNOGDI',
> > '-DNO_POSIX_GOODIES',
> > @@ -1328,6 +1327,18 @@ elif host_machine.system() == 'windows'
> > '-D__USE_MINGW_ANSI_STDIO=0',
> > ]
> >
> > + msystem = get_option('msystem')
> > + if msystem != ''
> > + mingw_prefix = get_option('mingw_prefix')
> > + if mingw_prefix == ''
> > + mingw_prefix = '/' + msystem.to_lower()
> > + endif
> > + libgit_c_args += [
> > + '-DENSURE_MSYSTEM_IS_SET="' + msystem + '"',
> > + '-DMINGW_PREFIX="' + mingw_prefix + '"'
> > + ]
> > + endif
>
> Lowercase mingw_prefix in Meson world corresponds to MINGW_PREFIX in
> Make world, I guess. -DMINGW_PRFIX gets mingw_prefix which begins
> with a slash.
>
> I do not do Windows or Meson, but doesn't this contradict with what
> we have in [12/12], part of which says:
>
> diff --git a/config.mak.uname b/config.mak.uname
> index 2f7d445eb3..0b63be10b7 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -535,7 +535,9 @@ endif
> compat/win32/pthread.o compat/win32/syslog.o \
> compat/win32/trace2_win32_process_info.o \
> compat/win32/dirent.o
> - COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
> + COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY \
> + -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" -DMINGW_PREFIX="\"$(patsubst /%,%,$(MINGW_PREFIX))\"" \
> + -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
> BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -ENTRY:wmainCRTStartup -SUBSYSTEM:CONSOLE
> # invalidcontinue.obj allows Git's source code to close the same file
> # handle twice, or to access the osfhandle of an already-closed stdout
>
>
> IOW, -DMINGW_PREFIX passed to the compiler strips leading slash from
> $(MINGW_PREFIX).
>
> Isn't it necessary to strip the leading slash from ming_prefix also
> on the Meson side?
Correct. Since Git for Windows does not use Meson to build the project,
and since the Visual C-based builds (including CI's `windows-meson-build`)
do not use `MSYSTEM`, this was not caught earlier. The next iteration will
have the fix.
Ciao,
Johannes
dscho
force-pushed
the
upstream-some-more-git-for-windows-patches
branch
from
August 6, 2026 08:43
f822133 to
679d1fd
Compare
|
This branch is now known as |
|
This patch series was integrated into seen via git@8b87133. |
| @@ -3134,6 +3134,45 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t utflen) | |||
| return -1; | |||
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> @@ -3186,6 +3225,32 @@ static void setup_windows_environment(void)
> setenv("HOME", tmp, 1);
> }
>
> + if (!getenv("PLINK_PROTOCOL"))
> + setenv("PLINK_PROTOCOL", "ssh", 0);
> +
> +#ifdef ENSURE_MSYSTEM_IS_SET
> + if (!(tmp = getenv("MSYSTEM")) || !tmp[0]) {
Checking tmp[0] is a sign that we do not consider MSYSTEM set to an
empty string a sane state and ENSURE_MSYSTEM_IS_SET is about
correcting it, right?
> + const char *home = getenv("HOME"), *path = getenv("PATH");
> + char buf[32768];
> + size_t off = 0;
> +
> + setenv("MSYSTEM", ENSURE_MSYSTEM_IS_SET, 1);
In config.mak.uname, ENSURE_MSYSTEM_IS_SET is defined to "$(MSYSTEM)".
+ COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY \
+ -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" -DMINGW_PREFIX="\"$(patsubst /%,%,$(MINGW_PREFIX))\"" \
Can $(MSYSTEM) be an empty string or undefined at the build time,
making ENSURE_MSYSTEM_IS_SET set to "" (two double-quotes)? Which
would mean we are exporting MSYSTEM defined to be an empty string as
well with this setenv.
It seems ifeq($(uname_S),MINGW) side protects against this situation
by placing the cflags definition
+ COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
+ -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" \
inside "ifneq (,$(MSYSTEM))..endif". That way, ENSURE_MSYSTEM_IS_SET
is not defined to "" (two double-quotes), so #ifdef ENSURE_MSYSTEM_IS_SET
would not kick in.
There was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Junio,
On Thu, 6 Aug 2026, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > @@ -3186,6 +3225,32 @@ static void setup_windows_environment(void)
> > setenv("HOME", tmp, 1);
> > }
> >
> > + if (!getenv("PLINK_PROTOCOL"))
> > + setenv("PLINK_PROTOCOL", "ssh", 0);
> > +
> > +#ifdef ENSURE_MSYSTEM_IS_SET
> > + if (!(tmp = getenv("MSYSTEM")) || !tmp[0]) {
>
> Checking tmp[0] is a sign that we do not consider MSYSTEM set to an
> empty string a sane state and ENSURE_MSYSTEM_IS_SET is about
> correcting it, right?
"sane state" is quite the strong wording for such a minor issue.
The MSYSTEM variable is useful as an indicator, and is therefore used in
many scripts. Git itself only uses it as a tell-tale that a GUI should be
used in `git bisect visualize`, otherwise Git is totally fine with empty
or even non-sensical values.
But it _is_ a convenient thing to have, together with `MINGW_PREFIX` to
ensure that the respective `/*/bin/` directories are prepended to the
`PATH` variable. That's what this is all about.
>
> > + const char *home = getenv("HOME"), *path = getenv("PATH");
> > + char buf[32768];
> > + size_t off = 0;
> > +
> > + setenv("MSYSTEM", ENSURE_MSYSTEM_IS_SET, 1);
>
> In config.mak.uname, ENSURE_MSYSTEM_IS_SET is defined to "$(MSYSTEM)".
>
> + COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY \
> + -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" -DMINGW_PREFIX="\"$(patsubst /%,%,$(MINGW_PREFIX))\"" \
>
> Can $(MSYSTEM) be an empty string or undefined at the build time,
> making ENSURE_MSYSTEM_IS_SET set to "" (two double-quotes)?
Sure it can. Just like `PATH` or `HOME` can be empty, or invalid. But the
person building the project has to go out of their way to make it so,
therefore I don't want to spend any more brain cells on that highly
unlikely scenario.
Ciao,
Johannes
> Which would mean we are exporting MSYSTEM defined to be an empty string
> as well with this setenv.
>
> It seems ifeq($(uname_S),MINGW) side protects against this situation
> by placing the cflags definition
>
> + COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
> + -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" \
>
> inside "ifneq (,$(MSYSTEM))..endif". That way, ENSURE_MSYSTEM_IS_SET
> is not defined to "" (two double-quotes), so #ifdef ENSURE_MSYSTEM_IS_SET
> would not kick in.
>
> There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Checking tmp[0] is a sign that we do not consider MSYSTEM set to an
>> empty string a sane state and ENSURE_MSYSTEM_IS_SET is about
>> correcting it, right?
>
> "sane state" is quite the strong wording for such a minor issue.
Well I didn't know how important that variable is, and didn't expect
or wish to offend you by use of that word. Perhaps "sane"->"usual"
would have been better? Sorry about uninformed choice of phrasing.
>> Can $(MSYSTEM) be an empty string or undefined at the build time,
>> making ENSURE_MSYSTEM_IS_SET set to "" (two double-quotes)?
>
> Sure it can. Just like `PATH` or `HOME` can be empty, or invalid. But the
> person building the project has to go out of their way to make it so,
> therefore I don't want to spend any more brain cells on that highly
> unlikely scenario.
Again, I didn't know how unlikely it was, so I judged it based on
the existing practice (quoted) below.
> Ciao,
> Johannes
>
>> Which would mean we are exporting MSYSTEM defined to be an empty string
>> as well with this setenv.
>>
>> It seems ifeq($(uname_S),MINGW) side protects against this situation
>> by placing the cflags definition
>>
>> + COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
>> + -DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" \
>>
>> inside "ifneq (,$(MSYSTEM))..endif". That way, ENSURE_MSYSTEM_IS_SET
>> is not defined to "" (two double-quotes), so #ifdef ENSURE_MSYSTEM_IS_SET
>> would not kick in.
>>
>>
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Expecting a reroll. cf. <9f905100-003b-8ef2-3e2e-2f9ed57dda1b@gmx.de> source: <pull.2195.git.1785939999.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Expecting a reroll. cf. <9f905100-003b-8ef2-3e2e-2f9ed57dda1b@gmx.de> source: <pull.2195.git.1785939999.gitgitgadget@gmail.com> |
Member
Author
|
/submit |
|
Submitted as pull.2195.v2.git.1786521173.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This patch series is no longer integrated into seen. |
|
This patch series was integrated into seen via git@c169b95. |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Needs review. source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Needs review. source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
| @@ -465,14 +465,8 @@ ifeq ($(uname_S),Windows) | |||
| GIT_VERSION := $(GIT_VERSION).MSVC | |||
There was a problem hiding this comment.
Johannes Sixt wrote on the Git mailing list (how to reply to this email):
Am 12.08.26 um 09:52 schrieb Johannes Schindelin via GitGitGadget:
> diff --git a/config.mak.uname b/config.mak.uname
> index 21f53e3f7e..3a90995587 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -465,14 +465,8 @@ ifeq ($(uname_S),Windows)
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> # Assume that this is built in Git for Windows' SDK
> - ifeq (MINGW32,$(MSYSTEM))
> - prefix = /mingw32
> - else
> - ifeq (CLANGARM64,$(MSYSTEM))
> - prefix = /clangarm64
> - else
> - prefix = /mingw64
> - endif
> + ifneq (,$(MSYSTEM))
> + prefix = $(MINGW_PREFIX)
> endif
> # Prepend MSVC 64-bit tool-chain to PATH.
> #
> @@ -755,6 +749,10 @@ ifeq ($(uname_S),MINGW)
> BASIC_LDFLAGS += -Wl,--dynamicbase
> endif
> ifneq (,$(MSYSTEM))
> + ifeq ($(MINGW_PREFIX),$(filter-out /%,$(MINGW_PREFIX)))
> + # Override if empty or does not start with a slash
> + MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
> + endif
> prefix = $(MINGW_PREFIX)
> HOST_CPU = $(patsubst %-w64-mingw32,%,$(MINGW_CHOST))
> BASIC_LDFLAGS += -Wl,--pic-executable
At this point, MINGW_PREFIX is only used to set prefix.
Only in 12/12 is the variable (and ENSURE_MSYSTEM_IS_SET) used to drive
C code. Therefore, it seems that the following hunks concerning the
CMake and meson build systems do not belong in this patch, yet, but only
in 12/12.
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index a57c4b464f..7285bd9ac2 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -256,7 +256,14 @@ if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
> _CONSOLE DETECT_MSYS_TTY STRIP_EXTENSION=".exe" NO_SYMLINK_HEAD UNRELIABLE_FSTAT
> NOGDI OBJECT_CREATION_MODE=1 __USE_MINGW_ANSI_STDIO=0
> OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP
> - HAVE_WPGMPTR ENSURE_MSYSTEM_IS_SET HAVE_RTLGENRANDOM)
> + HAVE_WPGMPTR HAVE_RTLGENRANDOM)
> + if(CMAKE_GENERATOR_PLATFORM STREQUAL "x64")
> + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW64" MINGW_PREFIX="mingw64")
> + elseif(CMAKE_GENERATOR_PLATFORM STREQUAL "arm64")
> + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="CLANGARM64" MINGW_PREFIX="clangarm64")
> + elseif(CMAKE_GENERATOR_PLATFORM STREQUAL "x86")
> + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW32" MINGW_PREFIX="mingw32")
> + endif()
> list(APPEND compat_SOURCES
> compat/mingw.c
> compat/winansi.c
> diff --git a/meson.build b/meson.build
> index 7073d5844d..a8aba81e29 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1318,7 +1318,6 @@ elif host_machine.system() == 'windows'
>
> libgit_c_args += [
> '-DDETECT_MSYS_TTY',
> - '-DENSURE_MSYSTEM_IS_SET',
> '-DNATIVE_CRLF',
> '-DNOGDI',
> '-DNO_POSIX_GOODIES',
> @@ -1328,6 +1327,20 @@ elif host_machine.system() == 'windows'
> '-D__USE_MINGW_ANSI_STDIO=0',
> ]
>
> + msystem = get_option('msystem')
> + if msystem != ''
> + mingw_prefix = get_option('mingw_prefix')
> + if mingw_prefix == ''
> + mingw_prefix = msystem.to_lower()
> + elif mingw_prefix.startswith('/')
> + mingw_prefix = mingw_prefix.substring(1)
> + endif
> + libgit_c_args += [
> + '-DENSURE_MSYSTEM_IS_SET="' + msystem + '"',
> + '-DMINGW_PREFIX="' + mingw_prefix + '"'
> + ]
> + endif
> +
> libgit_dependencies += compiler.find_library('ntdll')
> libgit_include_directories += 'compat/win32'
> if compiler.get_id() == 'msvc'
> diff --git a/meson_options.txt b/meson_options.txt
> index dc88f130d7..becf4689bf 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -21,6 +21,10 @@ option('runtime_prefix', type: 'boolean', value: false,
> description: 'Resolve ancillary tooling and support files relative to the location of the runtime binary instead of hard-coding them into the binary.')
> option('sane_tool_path', type: 'array', value: [],
> description: 'An array of paths to pick up tools from in case the normal tools are broken or lacking.')
> +option('msystem', type: 'string', value: '',
> + description: 'Fall-back on Windows when MSYSTEM is not set.')
> +option('mingw_prefix', type: 'string', value: '',
> + description: 'Fall-back on Windows when MINGW_PREFIX is not set.')
>
> # Build information compiled into Git and other parts like documentation.
> option('build_date', type: 'string', value: '',
-- Hannes
There was a problem hiding this comment.
Junio C Hamano wrote on the Git mailing list (how to reply to this email):
Johannes Sixt <j6t@kdbg.org> writes:
> Am 12.08.26 um 09:52 schrieb Johannes Schindelin via GitGitGadget:
>> diff --git a/config.mak.uname b/config.mak.uname
>> index 21f53e3f7e..3a90995587 100644
>> --- a/config.mak.uname
>> +++ b/config.mak.uname
>> @@ -465,14 +465,8 @@ ifeq ($(uname_S),Windows)
>> GIT_VERSION := $(GIT_VERSION).MSVC
>> pathsep = ;
>> # Assume that this is built in Git for Windows' SDK
>> - ifeq (MINGW32,$(MSYSTEM))
>> - prefix = /mingw32
>> - else
>> - ifeq (CLANGARM64,$(MSYSTEM))
>> - prefix = /clangarm64
>> - else
>> - prefix = /mingw64
>> - endif
>> + ifneq (,$(MSYSTEM))
>> + prefix = $(MINGW_PREFIX)
>> endif
>> # Prepend MSVC 64-bit tool-chain to PATH.
>> #
>> @@ -755,6 +749,10 @@ ifeq ($(uname_S),MINGW)
>> BASIC_LDFLAGS += -Wl,--dynamicbase
>> endif
>> ifneq (,$(MSYSTEM))
>> + ifeq ($(MINGW_PREFIX),$(filter-out /%,$(MINGW_PREFIX)))
>> + # Override if empty or does not start with a slash
>> + MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
>> + endif
>> prefix = $(MINGW_PREFIX)
>> HOST_CPU = $(patsubst %-w64-mingw32,%,$(MINGW_CHOST))
>> BASIC_LDFLAGS += -Wl,--pic-executable
>
> At this point, MINGW_PREFIX is only used to set prefix.
>
> Only in 12/12 is the variable (and ENSURE_MSYSTEM_IS_SET) used to drive
> C code. Therefore, it seems that the following hunks concerning the
> CMake and meson build systems do not belong in this patch, yet, but only
> in 12/12.
Haven't heard anything on this topic for a few weeks. Can we
conclude it anytime soon? I do not like too many topics that are
almost there hanging around only because they miss the finishing
touches.
Thanks.There was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Hannes,
On Sat, 15 Aug 2026, Johannes Sixt wrote:
> Am 12.08.26 um 09:52 schrieb Johannes Schindelin via GitGitGadget:
> > diff --git a/config.mak.uname b/config.mak.uname
> > index 21f53e3f7e..3a90995587 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -465,14 +465,8 @@ ifeq ($(uname_S),Windows)
> > GIT_VERSION := $(GIT_VERSION).MSVC
> > pathsep = ;
> > # Assume that this is built in Git for Windows' SDK
> > - ifeq (MINGW32,$(MSYSTEM))
> > - prefix = /mingw32
> > - else
> > - ifeq (CLANGARM64,$(MSYSTEM))
> > - prefix = /clangarm64
> > - else
> > - prefix = /mingw64
> > - endif
> > + ifneq (,$(MSYSTEM))
> > + prefix = $(MINGW_PREFIX)
> > endif
> > # Prepend MSVC 64-bit tool-chain to PATH.
> > #
> > @@ -755,6 +749,10 @@ ifeq ($(uname_S),MINGW)
> > BASIC_LDFLAGS += -Wl,--dynamicbase
> > endif
> > ifneq (,$(MSYSTEM))
> > + ifeq ($(MINGW_PREFIX),$(filter-out /%,$(MINGW_PREFIX)))
> > + # Override if empty or does not start with a slash
> > + MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
> > + endif
> > prefix = $(MINGW_PREFIX)
> > HOST_CPU = $(patsubst %-w64-mingw32,%,$(MINGW_CHOST))
> > BASIC_LDFLAGS += -Wl,--pic-executable
>
> At this point, MINGW_PREFIX is only used to set prefix.
>
> Only in 12/12 is the variable (and ENSURE_MSYSTEM_IS_SET) used to drive
> C code. Therefore, it seems that the following hunks concerning the
> CMake and meson build systems do not belong in this patch, yet, but only
> in 12/12.
Ah, right, the following hunks do touch the ENSURE_MSYSTEM_IS_SET stuff.
But they _also_ add the `MINGW_PREFIX` stuff.
Will disentangle.
Ciao,
Johannes
>
> > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> > index a57c4b464f..7285bd9ac2 100644
> > --- a/contrib/buildsystems/CMakeLists.txt
> > +++ b/contrib/buildsystems/CMakeLists.txt
> > @@ -256,7 +256,14 @@ if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
> > _CONSOLE DETECT_MSYS_TTY STRIP_EXTENSION=".exe" NO_SYMLINK_HEAD UNRELIABLE_FSTAT
> > NOGDI OBJECT_CREATION_MODE=1 __USE_MINGW_ANSI_STDIO=0
> > OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP
> > - HAVE_WPGMPTR ENSURE_MSYSTEM_IS_SET HAVE_RTLGENRANDOM)
> > + HAVE_WPGMPTR HAVE_RTLGENRANDOM)
> > + if(CMAKE_GENERATOR_PLATFORM STREQUAL "x64")
> > + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW64" MINGW_PREFIX="mingw64")
> > + elseif(CMAKE_GENERATOR_PLATFORM STREQUAL "arm64")
> > + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="CLANGARM64" MINGW_PREFIX="clangarm64")
> > + elseif(CMAKE_GENERATOR_PLATFORM STREQUAL "x86")
> > + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW32" MINGW_PREFIX="mingw32")
> > + endif()
> > list(APPEND compat_SOURCES
> > compat/mingw.c
> > compat/winansi.c
> > diff --git a/meson.build b/meson.build
> > index 7073d5844d..a8aba81e29 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1318,7 +1318,6 @@ elif host_machine.system() == 'windows'
> >
> > libgit_c_args += [
> > '-DDETECT_MSYS_TTY',
> > - '-DENSURE_MSYSTEM_IS_SET',
> > '-DNATIVE_CRLF',
> > '-DNOGDI',
> > '-DNO_POSIX_GOODIES',
> > @@ -1328,6 +1327,20 @@ elif host_machine.system() == 'windows'
> > '-D__USE_MINGW_ANSI_STDIO=0',
> > ]
> >
> > + msystem = get_option('msystem')
> > + if msystem != ''
> > + mingw_prefix = get_option('mingw_prefix')
> > + if mingw_prefix == ''
> > + mingw_prefix = msystem.to_lower()
> > + elif mingw_prefix.startswith('/')
> > + mingw_prefix = mingw_prefix.substring(1)
> > + endif
> > + libgit_c_args += [
> > + '-DENSURE_MSYSTEM_IS_SET="' + msystem + '"',
> > + '-DMINGW_PREFIX="' + mingw_prefix + '"'
> > + ]
> > + endif
> > +
> > libgit_dependencies += compiler.find_library('ntdll')
> > libgit_include_directories += 'compat/win32'
> > if compiler.get_id() == 'msvc'
> > diff --git a/meson_options.txt b/meson_options.txt
> > index dc88f130d7..becf4689bf 100644
> > --- a/meson_options.txt
> > +++ b/meson_options.txt
> > @@ -21,6 +21,10 @@ option('runtime_prefix', type: 'boolean', value: false,
> > description: 'Resolve ancillary tooling and support files relative to the location of the runtime binary instead of hard-coding them into the binary.')
> > option('sane_tool_path', type: 'array', value: [],
> > description: 'An array of paths to pick up tools from in case the normal tools are broken or lacking.')
> > +option('msystem', type: 'string', value: '',
> > + description: 'Fall-back on Windows when MSYSTEM is not set.')
> > +option('mingw_prefix', type: 'string', value: '',
> > + description: 'Fall-back on Windows when MINGW_PREFIX is not set.')
> >
> > # Build information compiled into Git and other parts like documentation.
> > option('build_date', type: 'string', value: '',
>
> -- Hannes
>
> There was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Hannes,
On Wed, 9 Sep 2026, Johannes Schindelin wrote:
> On Sat, 15 Aug 2026, Johannes Sixt wrote:
>
> > Am 12.08.26 um 09:52 schrieb Johannes Schindelin via GitGitGadget:
> > > @@ -755,6 +749,10 @@ ifeq ($(uname_S),MINGW)
> > > BASIC_LDFLAGS += -Wl,--dynamicbase
> > > endif
> > > ifneq (,$(MSYSTEM))
> > > + ifeq ($(MINGW_PREFIX),$(filter-out /%,$(MINGW_PREFIX)))
> > > + # Override if empty or does not start with a slash
> > > + MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
> > > + endif
> > > prefix = $(MINGW_PREFIX)
> > > HOST_CPU = $(patsubst %-w64-mingw32,%,$(MINGW_CHOST))
> > > BASIC_LDFLAGS += -Wl,--pic-executable
> >
> > At this point, MINGW_PREFIX is only used to set prefix.
> >
> > Only in 12/12 is the variable (and ENSURE_MSYSTEM_IS_SET) used to drive
> > C code. Therefore, it seems that the following hunks concerning the
> > CMake and meson build systems do not belong in this patch, yet, but only
> > in 12/12.
>
> Ah, right, the following hunks do touch the ENSURE_MSYSTEM_IS_SET stuff.
> But they _also_ add the `MINGW_PREFIX` stuff.
Gah. My assessment is incorrect. At this point in the patch series, the
`MINGW_PREFIX` constant isn't used anywhere in the C code. So you were
absolutely right, those hunks do need to move to 12/12 wholesale.
Sorry about the slalom,
Johannes
|
User |
|
Johannes Sixt wrote on the Git mailing list (how to reply to this email): Am 12.08.26 um 09:52 schrieb Johannes Schindelin via GitGitGadget:
> Johannes Schindelin (12):
> mingw: include the Python parts in the build
> mingw: stop hard-coding `CC = gcc`
> mingw: drop the -D_USE_32BIT_TIME_T option
> mingw: only use -Wl,--large-address-aware for 32-bit builds
> mingw: avoid over-specifying `--pic-executable`
> mingw: set the prefix and HOST_CPU as per MSYS2's settings
> mingw: only enable the MSYS2-specific stuff when compiling in MSYS2
> mingw: rely on MSYS2's metadata instead of hard-coding it
> windows: skip linking `git-<command>` for built-ins
> mingw: always define `ETC_*` for MSYS2 environments
> mingw: ensure valid CTYPE
> mingw: allow `git.exe` to be used instead of the "Git wrapper"
I have been building my own Windows version with a subset of these
patches since November 25 already, specifically with 02-06, 08, and 09/12.
After building with all of these patches instead of just the subset, I
don't observe any negative effects after a quick check. CI is happy as
well (https://github.com/j6t/git/actions/runs/31831084178).
-- Hannes |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Waiting for response. cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org> source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com> |
That option only matters there, and is in fact only really understood in those builds; UCRT64 versions of GCC, for example, do not know what to do with that option. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In bf2d5d8 (Don't let ld strip relocations, 2016-01-16) (picked from git-for-windows@6a237925bf10), Git for Windows introduced the `-Wl,-pic-executable` flag, specifying the exact entry point via `-e`. This required discerning between i686 and x86_64 code because the former required the symbol to be prefixed with an underscore, the latter did not. As per https://sourceware.org/bugzilla/show_bug.cgi?id=10865, the specified symbols are already the default, though. So let's drop the overly-specific definition. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSYS2 already defines a couple of helpful environment variables, and we can use those to infer the installation location as well as the CPU. No need for hard-coding ;-) Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The tell-tale is the presence of the `MSYSTEM` value while compiling, of course. In that case, we want to ensure that `MSYSTEM` is set when running `git.exe`, and also enable the magic MSYS2 tty detection. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSYS2 defines some helpful environment variables, e.g. `MSYSTEM`. There is code in Git for Windows to ensure that that `MSYSTEM` variable is set, hard-coding a default. However, the existing solution jumps through hoops to reconstruct the proper default, and is even incomplete doing so, as we found out when we extended it to support CLANGARM64. This is absolutely unnecessary because there is already a perfectly valid `MSYSTEM` value we can use at build time. This is even true when building the MINGW32 variant on a MINGW64 system because `makepkg-mingw` will override the `MSYSTEM` value as per the `MINGW_ARCH` array. The same is equally true for the `/mingw64`, `/mingw32` and `/clangarm64` prefix: those values are already available via the `MINGW_PREFIX` environment variable, and we just need to pass that setting through. Only when `MINGW_PREFIX` is not set (as is the case in Git for Windows' minimal SDK, where only `MSYSTEM` is guaranteed to be set correctly), we use as fall-back the top-level directory whose name is the down-cased value of the `MSYSTEM` variable. Incidentally, this also broadens the support to all the configurations supported by the MSYS2 project, i.e. clang64 & ucrt64, too. Helped-by: Johannes Sixt <j6t@kdbg.org> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is merely a historical wart that, say, `git-commit` exists in the `libexec/git-core/` directory, a tribute to the original idea to let Git be essentially a bunch of Unix shell scripts revolving around very few "plumbing" (AKA low-level) commands. Git has evolved a lot from there. These days, most of Git's functionality is contained within the `git` executable, in the form of "built-in" commands. To accommodate for scripts that use the "dashed" form of Git commands, even today, Git provides hard-links that make the `git` executable available as, say, `git-commit`, just in case that an old script has not been updated to invoke `git commit`. Those hard-links do not come cheap: they take about half a minute for every build of Git on Windows, they are mistaken for taking up huge amounts of space by some Windows Explorer versions that do not understand hard-links, and therefore many a "bug" report had to be addressed. The "dashed form" has been officially deprecated in Git version 1.5.4, which was released on February 2nd, 2008, i.e. a very long time ago. This deprecation was never finalized by skipping these hard-links, but we can start the process now, in Git for Windows. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Special-casing even more configurations simply does not make sense. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes git-for-windows#1036 Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows wants to add `git.exe` to the users' `PATH`, without cluttering the latter with unnecessary executables such as `wish.exe`. To that end, it invented the concept of its "Git wrapper", i.e. a tiny executable located in `C:\Program Files\Git\cmd\git.exe` (originally a CMD script) whose sole purpose is to set up a couple of environment variables and then spawn the _actual_ `git.exe` (which nowadays lives in `C:\Program Files\Git\mingw64\bin\git.exe` for 64-bit, and the obvious equivalent for 32-bit installations). Currently, the following environment variables are set unless already initialized: - `MSYSTEM`, to make sure that the MSYS2 Bash and the MSYS2 Perl interpreter behave as expected, and - `PLINK_PROTOCOL`, to force PuTTY's `plink.exe` to use the SSH protocol instead of Telnet, - `PATH`, to make sure that the `bin` folder in the user's home directory, as well as the `/mingw64/bin` and the `/usr/bin` directories are included. The trick here is that the `/mingw64/bin/` and `/usr/bin/` directories are relative to the top-level installation directory of Git for Windows (which the included Bash interprets as `/`, i.e. as the MSYS pseudo root directory). Using the absence of `MSYSTEM` as a tell-tale, we can detect in `git.exe` whether these environment variables have been initialized properly. Therefore we can call `C:\Program Files\Git\mingw64\bin\git` in-place after this change, without having to call Git through the Git wrapper. Obviously, above-mentioned directories must be _prepended_ to the `PATH` variable, otherwise we risk picking up executables from unrelated Git installations. We do that by constructing the new `PATH` value from scratch, appending `$HOME/bin` (if `HOME` is set), then the MSYS2 system directories, and then appending the original `PATH`. Side note: this modification of the `PATH` variable is independent of the modification necessary to reach the executables and scripts in `/mingw64/libexec/git-core/`, i.e. the `GIT_EXEC_PATH`. That modification is still performed by Git, elsewhere, long after making the changes described above. While we _still_ cannot simply hard-link `mingw64\bin\git.exe` to `cmd` (because the former depends on a couple of `.dll` files that are only in `mingw64\bin`, i.e. calling `...\cmd\git.exe` would fail to load due to missing dependencies), at least we can now avoid that extra process of running the Git wrapper (which then has to wait for the spawned `git.exe` to finish) by calling `...\mingw64\bin\git.exe` directly, via its absolute path. Testing this is in Git's test suite tricky: we set up a "new" MSYS pseudo-root and copy the `git.exe` file into the appropriate location, then verify that `MSYSTEM` is set properly, and also that the `PATH` is modified so that scripts can be found in `$HOME/bin`, `/mingw64/bin/` and `/usr/bin/`. This addresses git-for-windows#2283 Note: This keeps the same, hard-coded MSYSTEM platform support for CMake as before, and introduces an `msystem' and `mingw-prefix` knob for Meson (read: neither CMake nor Meson will automatically inherit the setting from the current build environment). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These days, the test cases are less free-form than in the wild old days of the Git project. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
upstream-some-more-git-for-windows-patches
branch
from
September 10, 2026 05:59
4a4f24a to
88403ff
Compare
Member
Author
|
/submit |
|
Submitted as pull.2195.v4.git.1789020327.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
This PR is a bit time-critical, as I need it to be able to merge git-for-windows/git-sdk-64#117 in preparation for Git v2.56.0-rc0, which is [due later today](https://gh.io/gitCal). Unfortunately, I didn't manage to get gitgitgadget/git#2195 accepted into upstream Git's `master` branch in time, so this PR gets a bit [ugly](https://kaikki.org/dictionary/German/meaning/v/vo/von%20hinten%20durch%20die%20Brust%20ins%20Auge.html). Here's the thing: I need to migrate Git for Windows' SDK from MINGW64 to UCRT64. The reason is that [MSYS2 deprecated the former](https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment), and so we _have to_ migrate to the latter. The natural inflection point to do this [would have been Git v3.0](git-for-windows/git#6018) but there is no clarity to be had about any concrete timeline regarding this big milestone, so the next best thing we in the Git for Windows project can do is to tie that migration (which comes at the price of dropping support for Windows 8.1) to Git for Windows v2.56.0, hence [the note in our release notes](https://github.com/git-for-windows/build-extra/blob/318a8bc04b37f26b4188ab515bbbef5531c82cc7/ReleaseNotes.md?plain=1#L41) (also in our previous v2.55.* announcements). Migrating this here GitHub Action to UCRT64 comes with a couple of challenges. First of all, the MSYSTEM environment variable and the paths of tools like `gcc.exe` change. This should all be handled transparently via this PR because we no longer default to `x86_64`, but we now default to `ucrt64`, where these variables are already set correctly (as verified by the [`ci-artifacts` workflow](https://github.com/git-for-windows/git-sdk-64/actions/workflows/ci-artifacts.yml?query=branch%3Aucrt64)). The next building block of this PR is that `x86_64` will be broken for a short time window once git-for-windows/git-sdk-64#117 is merged. I already have a branch to adapt to that: https://github.com/git-for-windows/setup-git-for-windows-sdk/compare/adapt-to-ucrt64-migration-of-git-sdk-64. I will open a PR once the PR build has a chance to succeed (i.e. when `git-sdk-64` migrated to UCRT64), and we will hopefully be able to merge it and release a new version of `setup-git-for-windows-sdk` swiftly, to keep that window during which `architecture: x86_64` is broken to a minimum. The biggest snag is that upstream Git didn't accept my patch series yet. Without it, upstream Git won't compile under UCRT64. So if we simply switched the default architecture to `ucrt64`, we would break every single CI build of git/git (but obviously not git-for-windows/git, because obviously I accepted those patches already). To avoid having these CI failures hit innocent Git contributors, here comes the _really ugly_ part of this PR. This GitHub Action learns about internal details of the Git project, details that it should not have needed to know about. It looks for a tell-tale in the current working directory to determine whether it is supposed to run the CI build on an unpatched Git source code that would fail to compile under UCRT64, and if that's the case, it will fall back to initializing a MINGW64 minimal SDK instead. I know this is ugly. It is still the best I can do under the circumstances. It was not my choice to have it this way. At least this way we can go forward with the migration without being blocked. To demonstrate that this hack works, I ran the Git CI [on Git for Windows' current `main` (plus minimal patches to use this PR branch)](https://github.com/dscho/git/actions/runs/34473178171/job/102859178168), you can see that it uses UCRT64 [here](https://github.com/dscho/git/actions/runs/34473178171/job/102857629949#step:4:6)), and also [on Git's `master` branch](https://github.com/dscho/git/actions/runs/34462962318) (plus same patches, see [the warning](https://github.com/dscho/git/actions/runs/34462962318/job/102865492269#step:3:12) that it had to fall back to MINGW64, and the correctly-set `MSYSTEM` [here](https://github.com/dscho/git/actions/runs/34462962318/job/102865492269#step:4:6)).
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> Originally, I noticed that these patches had not been upstreamed yet when
> rebasing a Git for Windows commit to enable Rust in Windows CI.
>
> Changes since v3:
>
> * Reinstated the fly-by style fix as a separate commit.
> * Added Helped-by trailers
> * Moved and reworded a paragraph from the commit message of 08/12 to 12/12;
> This should have been done as part of v2.
Having a reroll by the author makes my life easier ;-) Will replace,
and with J6t's earlier blessing, we can mark it for 'next'.
Thanks, both. |
gh-github-automation Bot
pushed a commit
to actions-marketplace-validations/git-for-windows_setup-git-for-windows-sdk
that referenced
this pull request
Sep 10, 2026
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
This patch series was integrated into seen via git@ef591f6. |
|
This patch series was integrated into next via git@0ce62cf. |
|
There was a status update in the "Cooking" section about the branch A collection of patches from Git for Windows has been upstreamed, mostly focusing on simplifying and robustifying build configurations for MinGW/MSYS2, dropping obsolete compatibility options, and allowing the main 'git.exe' to be used directly without the extra wrapper process on Windows. Will merge to 'master'. cf. <9f078382-411f-4865-9f01-4fe0b1ee118f@kdbg.org> source: <pull.2195.v4.git.1789020327.gitgitgadget@gmail.com> |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the imminent switch of Git for Windows from the old MINGW64 environment (that was deprecated by MSYS2) to the UCRT64 environment, this patch series became quite urgent; I will have to work around this patch series not yet being in
masterviasetup-git-for-windows-sdkto be able to switch without breaking Git's CI builds.Originally, I noticed that these patches had not been upstreamed yet when rebasing a Git for Windows commit to enable Rust in Windows CI.
Changes since v3:
Helped-bytrailersChanges since v2:
Changes since v1:
meson-side handling of theMINGW_PREFIXconstant (this was not noticed in the Git for Windows project because it does not use Meson to build the project).cc: Johannes Sixt j6t@kdbg.org